Previous Page TOC Next Page



- 8 -
Memory Management


I hear so much about managing this and that today that I often wonder how anyone gets any work done. Management tools abound to help people perform the complex task of making the most out of the resources they have available, whether it's people, equipment, or even components of that equipment. In this respect, using Windows NT is no different from any other aspect of life. You have to manage your resources carefully to get the biggest payback from your investment. If you spend all your time managing your resources, however, you won't get any return because you'll have spent everything before you start. Therein lies the challenge of managing resources without wasting them.

What are the resources you have to be so careful about? Memory and hard disk space are the two major concerns that come to mind. Of course, processor cycles are in there somewhere as well. You might not think about some resources right away, though. How valuable is your time, for example? Trading some memory or processor cycles for a big increase in your personal productivity can mean having more resources available for other people to use in the long run. For right now, take a close look at managing memory. I pursue the other topics later.



Looking Ahead: Chapter 9, "A Tale of Three File Systems," looks at managing your hard drive. Look at Chapter 13, "Exploiting Your Software," and Chapter 14, "Exploiting Your Hardware," if you need ideas for making better use of your existing software and hardware. Chapter 15, "Fonts and Printing," helps you understand printer management better. I've already presented some management topics in previous chapters. You'll get a better idea of how to manage your environment in Chapter 2, "Exploring the Interface." A look at Chapter 3, "Performance Primer," will show you techniques for getting the most from your system in regard to performance—the optimum use of processor cycles. Chapter 5, "Startup Shortcuts," gives you some tips on making your applications and data more convenient to access and therefore making optimum use of your time.

Managing memory was always a problem under Windows 3.x. The problem wasn't so much a matter of lack of memory as a lack of the tools required to adequately manage memory. The first thing you need to understand is that you must worry about two kinds of memory when you're working with Windows applications. You need enough system memory to load the application and any data files. Windows also needs enough system resources to load things—such as the windows, dialog boxes, and icons—that your application uses.

System memory is very difficult to pin down under Windows 3.x. When you look at the About box in Program Manager and see that you have 15MB of RAM and 55 percent system resources left, what does that really tell you? There are a few problems here. First, Windows 3.x always includes the amount of virtual memory it creates on disk in the number it provides for RAM. This means that you could have almost no physical memory left, and all your RAM is really on disk. A lack of physical memory under Windows 3.x always leads to disk thrashing, so Windows spends more time swapping things to disk than it does taking care of your application's needs. This is just one example of an improperly managed system.

What about the system resources number? Does it really tell you what kind of system resource you have? Windows 3.x actually has two system resources to worry about: user and GDI (graphics device interface). The first resource contains all your windows and other user presentation elements. The second resource contains all the graphics elements that make Windows a joy to use. A lack of one resource means closing some applications. A lack of the other might be cured by removing your wallpaper for a while. The difference is important. Wallpaper isn't a productivity enhancer; you can get by without it for a while. The same can't be said of an important application you might need to run.

Here's the problem: Windows 3.x never gives you enough information to manage those system resources. The About box tells you about the system resource with the least amount of memory left. Of course, this doesn't tell you which resource the number refers to or what is left of the other resource. So now what do you do? I usually got rid of my wallpaper long enough to see whether I had enough system resources to get the job done. If that didn't work, one of my applications had to bite the dust. This productive way of managing system resources usually cost me a lot more than it saved. With such wonderful tools available to the average user, it's no wonder that no one could manage their system resources under Windows 3.x without buying a third-party product.

Windows NT doesn't follow the example of its predecessor. It provides a lot of tools to manage your system resources. Chapter 3 looked at some of these tools. The short view is that Microsoft has finally provided at least a minimal set of tools to manage your memory (and other system resources). Those tools aren't automatic by any definition, and they don't provide the most detailed information, but at least they're available and they can get the job done. It's definitely a step in the right direction.



Peter's Principle: Management Versus Micro-Management

A good manager will often provide a little input and see what happens. If more input is required, fine; otherwise, the manager leaves his employees alone to get their jobs done in whatever way works for them. This is the kind of person everyone likes to work for, and he still manages to amaze his superiors with the amount of work he can accomplish. There isn't much of a secret to his success. Spending your time getting your work done instead of doing someone else's work is always more productive.

The other kind of manager is the micro-manager. He's the one you see following behind an employee at every step of every task. The only way to get the job done is his way. It might not be efficient—it might even be counterproductive for that particular employee—but at least he can always tell his superiors what the people under him are doing. This fellow will always fail to impress anyone.

You might become a micro-manager under Windows NT if you're not careful. A lot more tools are at your disposal, and it's easy to suppose that they are there for a reason. The truth of the matter is that even though you have more tools when using Windows NT, the operating system is actually better at managing its memory without any help from you. The tools are there so that you can better determine what kind of "little input" Windows NT needs.

When working with Windows NT, the best principle is to provide a little input and see what happens. If more input is required, fine. If not, you've got a fully tuned system that will get the job done for you. Let the system do the work it's designed to do until you see a good reason to provide that little bit of input.

Part VI, "Networking with Windows NT," also shows that memory management in a networking environment requires a little more input from you. The workstation version of Windows NT only requires a little more input because you won't use it to maintain connections with a lot of other people. The server version of Windows NT requires more input from you because you're usually trying to balance the memory load for a lot more people and that load will tend a change a lot more over the course of the day than it would for a workstation.


The problems with Windows 3.x don't stop at a lack of tools. I find myself constantly fighting to get enough of the type of memory I need at any given time. If I manage to get enough memory together to run a program that requires expanded memory and a page frame in a DOS window, I don't have enough conventional memory because my device drivers won't load high. (A page frame consumes a memory-killing 64KB of upper memory—more than enough to load one or two drivers.) It always seems that Windows 3.x can't provide the kinds of memory I need.

The bottom-line reason for all these memory problems under Windows 3.x is all the real-mode drivers and TSRs you have to load just to get your system running. My CONFIG.SYS and AUTOEXEC.BAT are filled with all kinds of entries, many of which are essential to configuring the machine the way I need to. I absolutely cannot get by without loading the drivers for my CD-ROM, yet these drivers consume about 62KB of RAM. My sound card consumes another memory-clogging 37KB—and don't forget about all those handy utilities that most people load. All these drivers mean that I need some form of advanced memory management to load some of it high. The alternative is to give up running some of my DOS applications—all of which assume I have at least 512KB of conventional memory free.

Unlike Windows 3.x, which has to have real-mode drivers, and Windows 95, which can use real-mode drivers for compatibility purposes, you don't have any real-mode drivers or TSRs to worry about under Windows NT. In a way, this makes Windows NT the easiest of the three products to manage from one perspective: You don't have to worry about real mode creeping into your system. This convenience has a price to pay. I have an older CD-ROM drive that works fine under Windows 3.x; I replaced it under Windows 95, not because I couldn't use it, but because I wanted to get rid of the real-mode driver. This same CD-ROM drive won't work at all under Windows NT because it requires a real-mode driver.

Here is the crux of the matter. Under Windows 95, I had the choice of replacing the aging CD-ROM drive. Windows NT would have forced me to replace that drive because it wouldn't accept the real-mode driver used by the drive. If you run into the same situation and your company doesn't have any plans to replace your aging equipment (at least not right this second), you could run into a situation where Windows NT provides less—not more—capabilities that its predecessors. The memory management you gain will come at the expense of lost equipment capability. The fact you need to consider is that Windows NT equates to no real mode—a rather large inconvenience if you don't have the most modern equipment available or you need to use a specialty device of some kind. Consider for a second some of the full-page displays available for desktop publishing. A good number of these displays require a driver. If you just happened to have a driver that works with Windows NT, you're in good shape. Otherwise, you'll have to use Windows 95 or get along without the monitor.

Memory Types


Windows NT always starts in protected mode. Because it starts in this mode, the only memory it's concerned with during the startup cycle is extended memory. After it gets started, however, Windows provides access to a variety of memory types to accomplish a variety of tasks. Some of them relate to Windows itself; others relate to the applications that Windows supports. The following list describes these memory types:


Conventional Memory


Unlike Windows 3.x and Windows 95, Windows NT runs entirely in protected mode; it doesn't need real mode and the conventional memory associated with it. Just about everyone has some DOS applications they need to run, though, and every DOS application needs conventional memory. You could easily get mired in a lot of details when running DOS applications under Windows NT, but here's the short view: You can't use a memory manager under Windows NT. The only way to gain more memory is to change the way Windows NT allocates conventional memory. If you have an application that wants more memory than Windows NT can provide, you'll need to use Windows 3.x or Windows 95 to run it.



Tip: A lot of the trade papers are saying that corporate America wants to use Windows NT for stability and reliability reasons—a good reason to use it. On the other hand, Windows 95 provides many enhanced features for running problem DOS applications, including MS-DOS mode. People think MS-DOS mode is a "bad" way to run your applications; in reality, there's nothing bad about using MS-DOS mode at all. If you find that you have one application that requires more conventional memory than your standard setup supports, running it in MS-DOS mode might be the way to go. The whole idea of MS-DOS mode is to provide the flexibility you need in order to run demanding applications without giving up the overall efficiency of a hands-off setup. This doesn't just apply only to applications that won't cooperate with Windows 95; it applies to applications with special needs, too. If you have an application with special conventional memory needs, Windows 95 with its MS-DOS mode features might be the way to go short of buying a new 32-bit version of your application.

Later in this chapter, I cover the use of the Program Properties dialog box, which is where you should work on creating the perfect environment for your application. In most cases, the 600+KB of conventional memory you can achieve using the automatic Windows NT settings provides more-than-sufficient memory for your applications.

Upper Memory


The first thing you need to know about upper memory is what it is. Upper memory consists of six 64KB segments between 640KB and 1MB. Originally, IBM called this area reserved memory. They had reserved it for add-on peripherals and BIOS extensions. The current term for this area of real-mode addressable memory is the upper memory block (UMB). Microsoft invented the term UMB when programmers learned how to circumvent IBM's original plan. Faced with a demand for more conventional memory, programmers from Quarterdeck Office Systems figured out how to use the "reserved" area as additional space for user programs. Microsoft eventually incorporated some of these techniques into DOS (starting with version 5.0).

To access the UMBs under Windows NT, you need to add the following memory manager commands to your CONFIG.NT file: DEVICE=HIMEM.SYS and DEVICE=EMM.SYS. These two commands make the upper memory available to the current DOS session. Use the LoadHigh command in the CONFIG.NT file to load device drivers high. The same command in the AUTOEXEC.NT file loads TSRs high. You must exercise caution when choosing a program to load. Windows NT won't allow any of your programs to directly access the hardware (at least not hardware shared by the rest of the system), which makes the number of choices available somewhat limited. I'll discuss this issue in further detail in Chapter 13.

Sometimes, UMBs do come in handy. What if you have a device that uses a real-mode driver and it's very unlikely that the vendor will ever produce a Windows NT-specific version? Suppose that you have a data-collection device that uses a DOS data manager, and the manager needs every bit of conventional memory it can get. You need the UMB to load the device driver. Loading the device driver high frees the conventional memory you need to load the data manager that uses it. I find the only problem with loading a real-mode driver under Windows NT is that the operating system tends to reject it. Sometimes, you might not have the option of loading a driver into the UMB. Windows NT allows you to load it low but won't allow you to load it high. It's the price you pay for all that extra stability.

Surely, hardware that has probably outlived its useful life span doesn't have to give you nightmares. Although sometimes it seems that you have problems with a special-purpose device no matter what you do, you can still get around the problem. I follow one of three routes in such situations. The following list shows these routes in order of preference from a system reliability point of view. You have to choose the route you want to use based on personal needs and system requirements.


Expanded Memory


Anyone who has been computing very long will run into the need for expanded memory (EMS) at some point. EMS first appeared in 1985 as a means to bypass the DOS address limitations. Spreadsheet users were complaining that they didn't have enough memory to run those gargantuan worksheets anymore. These were the same folks who kept expanding the memory envelope throughout most of the PC's early history. This initial version enabled you to place data but not code in the expanded memory area. The spreadsheet users and, to a larger degree, database users were happy for a while but not forever.

In 1985, the buying public put considerable pressure on software vendors to find more memory for spreadsheet and database applications. This meant running code in the expanded memory area. Remember that most users didn't have any extended memory yet. The 80386 had just appeared on the scene, and the 80286 wasn't what you would call a good extended-memory candidate. The alternative was to handle large files by swapping information to the hard disk—a slow and unwieldy procedure. If the user paged down in a spreadsheet or address list, the application would pause to read the next page from disk.

Adding to this already-bad situation was the proliferation of TSR utilities that popped up over the user's display. Every one of these programs had to load in conventional memory because UMBs didn't exist yet. It's hard to remember sometimes just how crunched memory could get under those old versions of DOS. Let's take a quick stroll down memory lane and look at the history of EMS before I get into the Windows NT specifics.

EMS Version 3.0

Lotus and Intel announced EMS version 3.0 at the spring Comdex convention in 1985. This specification was designed to head off the rapid demise of 8088/8086 machines. This specification was short-lived, however, because Microsoft almost immediately announced that it would support EMS in the fall of 1985. Microsoft further promised to enhance Windows to use the memory made available by EMS hardware and software.

LIM EMS Version 3.2

The LIM expanded-memory standard, version 3.2, was a joint effort of three companies: Lotus, Intel, and Microsoft. LIM 3.2 memory allowed 1-2-3, Symphony, dBASE III, and Framework to keep relatively large data files in memory. Before expanded memory was introduced, the only way to manipulate large spreadsheets was to swap portions to and from disk. Under LIM 3.2, the user could add memory cards containing from 64KB to 8MB of RAM using expansion slots on the PC's bus. Only the expanded memory manager (EMM) could address all the memory; DOS looked at a 64KB window (called a page frame) supplied by the EMM in the upper memory area. The page frame was placed in reserved memory between 640KB and 1MB. Usually, this page frame appeared at segment D000h, but other page frame segments were used as well. All PCs (including 8088 machines) could use LIM 3.2 memory to ferry information to applications from the expanded memory card.

The LIM 3.2 EMM could tag and stash 16KB chunks of data, shipping them to the "warehouse" of extra RAM on the expanded memory card. When an application claimed the data, the EMM placed it back into the page frame 16KB at a time. Storing data in expanded memory was similar to storing it on a RAM disk; applications could retrieve the information without time-consuming hard disk access. Figure 8.1 illustrates how the LIM 3.2 EMM ferries data between expanded memory and DOS using the EMS page frame.

Figure 8.1. LIM EMS 3.2 uses 4KB to 16KB pages to store data required for any application running under DOS.

EEMS

The LIM EMS 3.2 standard was fine for storing data such as spreadsheets, but PC users wanted even more power from their machines. Utilities that performed background processing, such as Print and Sidekick, whetted the PC user's appetite for multitasking. Even the most sophisticated TSR, however, left a lot to be desired when compared to the features of a full-fledged application. Users wanted memory to multitask DOS applications.

Unfortunately, LIM EMS 3.2 provided neither the hardware basis nor the software interface to multitask applications. An application couldn't use LIM EMS 3.2 memory to run program code, for example. This annoying limitation of LIM EMS 3.2 was tied to the fact that DOS couldn't directly access the expanded memory hardware; only the EMM was allowed to do that. In addition, the memory-mapping hardware limited the size and location of each page in the page frame.

In 1986, AST Research Corporation, QUADRAM Corporation, and Ashton-Tate added some enhancements to the Lotus-Intel-Microsoft specification. Their improved standard, Enhanced Expanded Memory Specification (EEMS), was a breakthrough in the PC industry.

EEMS revised the hardware functions of memory cards to improve the software standard. With EEMS, areas larger than 64KB could be used as a page frame. The page frame could be mapped below 640KB, as well as between 640KB and 1MB. This permitted entire programs to run in enhanced expanded memory.

When AST Research's EEMS cards were combined with Quarterdeck's DESQview, PCs had the capability to multitask a number of applications exceeding 640KB. A communications program could download files while a spreadsheet was recalculated. The user could type a document in a word processor and format a floppy disk concurrently.

LIM EMS Version 4.0

Lotus, Intel, and Microsoft eventually recognized the superiority of EEMS over LIM 3.2. In 1987, the LIM partners collaborated with AST Research, QUADRAM, and Ashton-Tate to define a new joint standard called LIM EMS Version 4.0. EMS 4.0 superseded AST's EEMS by allowing the memory manager to control 32MB of expanded memory instead of 8MB. It incorporated many, but not all, of the features provided by EEMS. Improvements of EMS 4.0 over EMS 3.2 include the following:


How EMS 4.0 Works

EMS 4.0 has many differences from its predecessors. Under EMS 4.0, allocated expanded memory can be mapped as conventional memory. The memory is usually divided into 16KB segments called standard pages. A program can use pages other than the standard 16KB size, however. These pages are called raw pages. Obviously, determining the number of pages of memory available is no longer a matter of simply knowing how many 16KB segments are installed, so EMS 4.0 also provides methods of determining the number of raw and standard pages.

Instead of only providing access to expanded memory through the page frame (as LIM 3.2 memory does), any number of standard or raw pages can be mapped between conventional memory and the RAM set aside for EMS. In addition, EMS 4.0 provides methods of moving memory regions between conventional and expanded memory. This makes it possible to execute multiple programs up to the full 640KB address range. The same EMM addresses both the conventional and expanded memory storage areas. To perform this task, the EMM marks a block of EMS memory for each program and assigns it an EMS handle. An EMS handle works and acts much like a DOS file handle, so programmers can easily make the transition in terms of understanding how the process works.

Other, more subtle differences include handle management. EMS 3.2 had no standard technique for managing handles. EMS 4.0 provides the means to get, set, and search for handle names. This enables an application to determine not only what memory is in use, but also who owns it.

Even with these changes, however, it would be impossible to run specific types of programs without another capability added to EMS 4.0. Some programs perform direct memory access (DMA) transfers. Many backup programs and some telecommunications programs do this, for example. It would take too long to transfer information one byte at a time through the processor, so the program creates a direct link between one storage device and another. Unlike EMS 3.2, EMS 4.0 allows specific types of DMA transfers to occur. This is made possible through the use of alternative register sets, part of the hardware (or hardware emulation). Alternative register sets also allow a whole range of other unique and powerful software management routines, many of which are at the operating system level.

One of the most unique differences between the two versions is that EMS 4.0 provides the means to allow the contents of expanded memory to survive a warm boot. DESQview uses this capability to enable you to reboot a hung window without affecting any other windows. Of course, should the errant application affect the memory containing the EMM, your only recourse is the big red switch. Figure 8.2 depicts some of the differences between EMS 3.2 and EMS 4.0.

Figure 8.2. Differences in the way that LIM EMS 3.2 and 4.0 get the job done.

VCPI Versus DPMI

You might be tempted to say that everything DOS needs to multitask is provided by EMS 4.0. Nothing could be further from the truth. The Extended Memory Specification (XMS) doesn't really do the job either. Both of these specifications deal with the availability of memory, but not necessarily how to control it. Think about the memory provided by EMS or XMS as city streets. Your application is a car traveling on that street. It needs the road to get from point A to point B. If you started running more than one application, there would be one car for each application and the street would begin to fill with traffic. What would happen if there were no traffic lights? Cars could still move around on the streets, but they would crash into each other because there wouldn't be any way to control their movement.

Applications need traffic lights in order to multitask successfully. An 80386 multitasks DOS applications in virtual 8086 mode. DOS extenders operate in protected mode. To avoid conflicts between programs using virtual 8086 mode and programs running in protected mode, a standard was devised by Quarterdeck, Rational Systems, Phar Lap, and other companies. The Virtual Control Program Interface (VCPI) is the standard that allows DOS extended programs to coexist in an 80386 multitasking environment. In other words, VCPI adds traffic lights to our city streets and keeps applications from crashing into each other. Under VCPI, users of DESQview can run protected-mode AutoCAD, 1-2-3, or Paradox side by side with other DOS applications.

Curiously, IBM and Microsoft didn't choose to actively support VCPI. Perhaps in 1988 and 1989, they expected that OS/2 would soon replace DOS, so it wasn't worth the trouble. In 1990, Microsoft premiered its own independent, protected-mode standard called the DOS Protected-Mode Interface (DPMI). This is the function of the HIMEM.SYS entry in CONFIG.SYS. Microsoft developed DPMI specifically for Windows 3.0, and it has been used ever since (even Windows NT automatically loads it as part of the VDM). Like VCPI, DPMI provides mode switching and extended memory management to client programs.

Unfortunately, Microsoft's DPMI standard for Windows is incompatible with the VCPI DOS extender software. In most cases, users can't run the old 386 versions of Paradox, AutoCAD, and so on as DOS tasks under Windows. Microsoft eventually agreed to participate in a committee that included representatives from Quarterdeck, Intel, Lotus, Phar Lap, and Rational Systems. The committee's goal was to develop a more generic version of DPMI. The resulting standard, DPMI Version 1.0, is fully VCPI-compatible; so far, though, Microsoft hasn't implemented DPMI 1.0 in Windows. Version 3.x of Windows still uses Microsoft's older DPMI 0.9—the version that's incompatible with VCPI DOS extenders.

The thinking in 1991 was that if Microsoft wouldn't go to the mountain, other companies would accommodate Microsoft. In July 1991, Rational Systems introduced a series of 32-bit DOS extenders designed to be Windows 3.x-compatible, even under the older standard. Even these extenders failed to make the grade, though. The result, of course, is that the world is using DPMI now. Programs that use VCPI are probably sitting on a shelf somewhere. Of course, now that no one is using VCPI, Microsoft graciously decided to add VCPI support to EMM386. This entire story probably has a profound moral, but I've yet to see it. You can run those old moth-eaten VCPI applications if you really want to, but a new Windows version of the application would probably give you a lot more in the way of features and stability.

Using EMS with Windows NT

The simple way to get expanded memory under Windows NT is to select the appropriate settings in the Programs Properties dialog box. In fact, this is about the only way to get it short of adding HIMEM.SYS and EMM.SYS to your CONFIG.NT file. Chapter 13 looks at this dialog box in detail. For right now, the important thing to remember is that Windows NT requires a different EMS strategy than previous versions of Windows. For one thing, you don't have the option of loading the memory manager before you start Windows—an option that still exists under Windows 95 (although I wouldn't even recommend using it there).



Tip: Many TSRs provide some method of loading themselves into expanded or extended memory. The TSR normally leaves a small 1KB to 2KB footprint in conventional memory but loads the rest of itself where your DOS application can't see it. I always create DOS boxes with the automatic maximum amount of both expanded and extended memory. That way, both types are available whenever I need them to load a TSR out of reach. Using this method enables you to load the TSR high without killing your conventional memory settings.


Extended Memory


Microsoft's Extended Memory Specification (XMS) got its start from the discovery of a Quarterdeck programmer in 1986. At the time, Quarterdeck was looking for any means possible to reduce the conventional memory overhead of DESQview, its multitasking product. Here is a quick view of what they discovered.

A standard PC breaks the first megabyte of memory into 16 64KB address segments. To produce an address, the processor combines this 16-bit segment with a 16-bit offset. The result of combining these two numbers is a 20-bit address. Each of these 20 bits controls an address-line gate circuit. The address lines are numbered A0 through A19. Each address line can contain a 1 or a 0, resulting in 2[20] or 1,048,576 memory locations (1MB).

The A20 gate circuit (the 21st address line) isn't present in the original 8088 version of the PC. Therefore, when an address exceeds the amount addressable by 20 address lines, it simply wraps to low memory. If you have segment FFFFh and offset 0010h, for example, the resulting address is 100000h. The original PC simply lops the 1 off the left and ends up with address 00000h. Instead of ending up near the very end of memory, you're at the very beginning.

The Quarterdeck programmer discovered that turning on the A20 gate of an 80286/80386/80486 chip also turned off the wraparound. Because these chips do have a twenty-first address line (actually, the 80286 has 24 and the 80386 and 80486 have 32), you can address the additional memory as if it were conventional memory. If a program was instructed to load code between 960KB and 1024KB, up to 64KB of code could spill over into the first segment beyond 1024KB. DOS could actually address code placed in the first segment of extended memory. Because the last segment of DOS memory isn't usually contiguous with conventional memory, programs can't use it automatically. The last segment of DOS memory can be specially programmed to hold up to 64KB of a single device driver or application program.

This bug (or feature) of the 80286 and above architecture prompted Quarterdeck to develop its QEXT.SYS device driver to reduce the conventional memory overhead of DESQview. In 1987, Microsoft formalized this quirk by issuing its own driver, HIMEM.SYS, and by naming the first segment above 1MB the high memory area (HMA). By publishing instructions on how to use the HMA, Microsoft enabled other third-party vendors to reduce the conventional overhead of their programs. Xerox was one of the first to recognize the HMA with Ventura Publisher. Microsoft's popularization of the HMA with HIMEM.SYS was the beginning of its Extended Memory Specification.

In 1990, Microsoft revised its HIMEM.SYS driver with the release of Windows 3.0. The scope of XMS memory was increased to include all of extended memory. The new release of Windows could use all of extended memory to multitask Windows applications. Disk caches, print spoolers, and RAM disks could now access extended memory through Microsoft's device driver. Formerly, any driver using extended memory had to provide its own scheme for switching in and out of protected mode. Microsoft established new terminology for all memory above 640KB:



Tip: TSRs almost always run faster in expanded memory than they do in extended memory. Try the TSR both ways to see which works best for you. I found that Collage (a screen-capture program) actually works faster when you load it into extended memory, for example.

As with expanded memory, Windows NT provides the means to precisely control how much extended memory you give to an application. Of course, you can always give it as much as it could possibly want by using the automatic settings. My system currently offers 23MB of extended memory to each DOS application if I use the automatic settings.

Virtual Memory


The first thing to understand is what virtual memory is and how it affects you as a user. In short, virtual memory is memory that Windows creates using your hard drive storage in place of RAM. In other words, it places some of the data you would usually see in RAM into a swap file on the hard drive. I take a look at the actual process of addressing memory later in this chapter. I include a detailed description of how virtual memory works under Windows NT, so I won't address that issue right now. Knowing the theory behind how something works and actually using that theory to do something useful, however, are two different things. I'm going to discuss some virtual memory usage tips in this section.

I've spent a lot of time in this chapter telling you how great the automated features of Windows NT are and how they will make your life easier and provide more flexibility. I've even gone so far as to say you'd be better off leaving them completely alone. Of course, you knew that wasn't going to last, didn't you? It's true that Windows NT does provide all those things, but I'm still talking about a piece of software that can't think independently the way you and I can. The problem with Windows NT is that it only looks for a "convenient" drive when it creates your swap file. It doesn't look at the speed of that drive or how you use it. That kind of thought process is something only you and I can accomplish. It's also the reason why you might want to manually adjust your machine's virtual memory settings in some cases.

Take my machine as a case in point. I have a small, fast drive and a larger, slow drive. The small drive contains some boot information, my DOS files, and a few other things I need to get my machine up and running or to figure out why it won't work. That drive has more than enough space left for a swap file. The faster speed of the drive and the fact that I very seldom change anything on it makes it the perfect location for a swap file. Of course, Windows NT is absolutely determined to use the slower, fragmented drive.



Tip: You can get a speed boost from your machine by hand-tuning the virtual memory setup in some cases. Generally, you'll want to allow Windows NT to choose the drive and the size of the swap files. Windows NT will sometimes choose the slowest drive on your machine, however. You can override this selection and choose the fastest drive. This means that you'll trade some extra speed for a little bit of flexibility. As soon as you turn off the automatic settings, you become responsible for adjusting the size of the swap file as required. (Of course, if Windows NT runs out of swap-file space before you adjust it, you get an error message when you try to run another application.)

Take a look at the process for changing your virtual memory setup. If you cut your teeth on Windows 3.x, you'll recognize the following dialog box even though it looks a bit different under Windows NT:

  1. Right-click My Computer and select the Properties option.

  2. Click the Performance tab. You should see the System Properties dialog box shown in Figure 8.3.

  3. Click the Virtual Memory button. You should see the dialog box shown in Figure 8.4.

    Figure 8.3. The Performance page of the System Properties dialog box provides access to the virtual memory settings for your machine.

    Figure 8.4. The Virtual Memory dialog box enables you to hand-tune your machine's virtual memory settings.

  4. Select the drive you want to use and then the amount you want to allocate for virtual memory.



Tip: Another way to get a little bit of a speed boost out of your virtual memory setup is to create a pseudo-permanent swap file. Under Windows 3.x, you could defragment your drive and then allocate a permanent swap file. Using this arrangement provides a noticeable speed boost because Windows can read from contiguous disk sectors instead of looking all over the drive for various pieces of the swap file. Microsoft claims that this is no longer necessary, but you can still get a speed boost by optimizing your drive and manually changing the virtual memory settings. All you need to do is select your fastest drive and set the minimum virtual memory setting to something other than 0. If you set the minimum and maximum size to the same value, you'll experience a lot less disk fragmentation and get a slight speed boost. Of course, you'll give up some flexibility to get this boost.

I would be remiss in my duty to you as an author if I didn't mention the Disable Virtual Memory checkbox near the bottom of the Virtual Memory dialog box. When Microsoft recommends that you not check it, they really mean it. I used to run Windows 3.x without any virtual memory management (VMM) because my system was actually faster without it. Under Windows NT, this has changed. Microsoft really did tune the VMM algorithms to a certain extent. You can't run Windows NT safely without a swap file. It depends on that swap file a lot more than Windows 3.x ever did, and it uses that swap file much more efficiently. Unless someone at Microsoft tells you to turn off the VMM for some type of maintenance check, leave it on.

That's about all there is to the VMM. It's not like Windows 3.x, where you could spend weeks just trying to figure out the best settings for a particular task. The only thing you need to worry about with Windows NT is choosing the fastest drive and making sure that it has enough space for the swap file. Making sure that the drive stays defragmented is one way to ensure that you always get the best performance. I also included a couple of tips in this section that you can use to get the optimum performance from your setup. VMM still isn't perfect under Windows NT, but it's a lot closer. The amount of tuning you need to do is a lot less under this new operating system. Of course, it would be nicer if you didn't have to tune the system at all. Maybe the next version of Windows will take us to that point.

Addressing Memory


If you think memory management under Windows NT is a simple matter, think again. Windows has many ways of looking at this critical resource, and it's important to understand how they differ. In the preceding section, I discussed the types of memory Windows NT uses or creates. Under Windows NT, extended memory is divided into two different memory-addressing models. This section discusses the two memory models that Windows uses to run the programs on your system: segmented and flat. All 16-bit Windows applications use the segmented memory model; 32-bit applications use the flat memory model. Of the two, flat is more efficient, but Windows needs to maintain both for compatibility reasons. The following sections explain why.

The Windows 3.1 Segmented Memory Model


I told you that the segmented memory model is a lot harder for a programmer to use than the flat memory model Windows uses with 32-bit applications. Of course, the first question that comes to mind is why Microsoft would even bother using the segmented memory model for enhanced-mode Windows 3.1. After all, enhanced mode is designed for the 80386, and you already know it supports the flat memory model. Microsoft had two good reasons for continuing to use the segmented memory model, however. First, the 80286 processor doesn't provide flat memory model support. If Microsoft had decided to use the flat memory model, it would have had to include a double set of files for every aspect of Windows 3.1. The second reason is equally simple. Windows 3.1 rides on top of DOS, and DOS uses 16-bit code. Windows 3.x already performs quite a juggling act in talking with DOS, and keeping a 32-bit ball up in the air as well would have been a little too much. As a result, Microsoft ended up with a 16-bit operating environment called Windows 3.1.

Now that you have a feel for why segmentation is still around, take a look at how it works. A segmented memory model uses two 16-bit registers to hold an address. In real mode, the processor uses a segment and an offset. Think of the segment as the street number and the offset as a specific house on that street. The processor combines the segment with the offset to create a 20-bit address for the 8086 or a 24-bit address for the 80286. Just how does it do this? The processor shifts the segment register's contents 4 bits to the right to make the transition. A 20-bit address yields the 1MB of address space that you've come to know and love when using DOS. Of course, the bottom line for the application is that the application, not the operating system, has control over the memory it uses.

Windows NT doesn't operate in real mode; it uses protected mode. The theory behind the protected-mode segmented memory model is slightly different from real mode. Look at Figure 8.5, which shows a simplified version of the protected-mode segmented memory model. Notice that it no longer uses a segment:offset pair, but a selector:offset pair. There's a big difference between a segment and a selector. A segment represents an actual location in memory, and a selector represents a position in a descriptor table. The table contains the actual location in memory. (It also contains a variety of other information that I won't cover here.)

Figure 8.5. Windows 3.x uses the segmented memory model shown here. Windows NT also uses this model for 16-bit applications.

How does this look-up table work? When Windows grants an application access to a specific range of memory, it gives that application a key to the memory range. That key is the selector. The application sends two values to the processor when it needs to access memory. The first value is the key (selector) that the processor needs to unlock the memory. The second value is the exact location (offset) within that range. Using selectors gives the operating system control over the entire range of memory on the system. Because an application must use a key to unlock its memory and only the processor knows the physical location of that memory, the system should be fairly secure.

In fact, the selector does provide some security information to the operating system. Bits 0 and 1 of the selector tell the operating system its privilege level. These levels equate to the rings of protection that I discuss later. Bit 0 (00b) provides the most privileged access and bit 3 (11b) provides the least privileged. All applications run at privilege level 3 under Windows; only the operating system runs at privilege level 0. Bit 2 contains the number of the table Windows should use to access the memory. The two descriptor tables are the global descriptor table (GDT) and the local descriptor table (LDT). A value of 1 selects the LDT. Windows uses the GDT for all common data. The entire system has only one GDT. Each application also has its own LDT for private data. Finally, bits 3 through 15 contain the actual index into the table.

Rather than get mired in a wealth of bits at this point, I'll just point out that Windows verifies that the application's security level is high enough to access the data it wants to see. It then takes the base address value (the protected-mode version of a segment) that it finds at the specified location in the descriptor table and combines it with the offset to find the physical location of the requested data in memory.

The segmented memory model has several problems. The biggest problem (if you're a programmer) is that you can allocate memory only in 64KB chunks. Remember, the address consists of a selector and an offset. Because the offset register is only 16 bits, it can handle only 64KB of memory. This means that the programmer has to write an application that manages a bunch of selectors, each pointing to a different 64KB chunk of memory. The chance of corrupting one of these selectors increases as the application uses more and more memory. It isn't too difficult to understand why a 16-bit Windows application could get confused and end up writing to the wrong section of memory. The results are usually catastrophic and end in a frozen machine.

Of course, the user faces a limitation here as well. Have you ever wondered where all those Out of memory messages come from? Many users have experienced the problem of Windows reporting that it has plenty of memory available and then deciding for no reason that it doesn't. Well, here's one culprit. Every icon, every dialog box, every menu, and every other resource you can imagine has to go somewhere in memory in order for Windows to use it. When Microsoft originally designed Windows 3.0, it decided that all those resources had to go into what programmers call the near heap—a 64KB chunk of global memory that Windows 3.0 sets aside for resources. Using the near heap increases execution speed—especially for time-consuming screen redraws—because the operating system isn't constantly manipulating selectors to access multiple 64KB chunks of memory. Needless to say, when you consider that just one icon is 766 bytes, you can see that it doesn't take too many of them to fill that 64KB heap.

After many user complaints about strange memory problems, Microsoft set aside two heaps in Windows 3.1. The first heap, the GDI heap, contains icons and other graphics resources. The other heap, the USER heap, contains nongraphics resources, such as dialog boxes. Even with two 64KB heaps, Windows 3.1 users still ran out of memory. You can easily determine whether you're about to run out of space in one of these two heaps. If you look at Program Manager's About dialog box, you'll notice a value that tells you the percentage of system resources—the amount of that 64KB chunk of memory that's left in the smallest heap. In other words, if the GDI heap has 20 percent of its space left and the USER heap has 30 percent, Windows will report a value of 20 percent (12.8KB) for system resources.

The Windows NT Flat Memory Model


When Microsoft designed Windows NT, it decided to use a different memory model supported by 80386 and above processors—the flat memory model. When the operating system places the processor in this mode, it essentially dictates that everything will use the same segment. The processor hasn't done away with segmentation, but the operating system chooses to ignore this capability. Eliminating segmentation greatly simplifies life for the programmer. No longer does the programmer need to worry about the segment registers; only the address is important.

Finding an Address

You might wonder how the operating system maintains control of memory using the flat addressing scheme. Under the segmented scheme, the processor maintained control through a table of selectors. The application used a selector as a key to open up a 64KB chunk of memory. The flat addressing mode has a protection scheme as well. In fact, this scheme provides even more flexibility than the segmented model. Figure 8.6 shows the flat memory model.

Figure 8.6. The flat address model doesn't use a selector:offset pair to address memory.

Each 32-bit address has three fields. Each field corresponds to one level of protection enforced by the processor under the flat memory model. Even though the programmer doesn't have to worry about these fields when writing an application, the operating system and processor do. The first field resides in bits 31 through 22 of the address. It points to an entry in the page table directory. Just like the segmented memory model, the flat model gives the application a key to a specific piece of memory—not its actual location. Locating the right page table is the first step in finding the address.

Take a moment to examine what a page table really is. Remember that in the segmented memory model, an application would have to allocate memory in 64KB chunks. If the application needed a larger allocation, it would have to ask for multiple chunks. A page table gets rid of this problem; the application simply asks for the total amount of memory it needs, and Windows provides it. The number of pages in this table corresponds to the number of 4KB pages the application allocates. If an application asked for 400KB of RAM, the table would contain 100 entries. As you can see, the flat address model is more flexible than the segmented model.

After Windows finds a specific page table, it uses the value in bits 21 through 12 of the address to find a specific page. Think back to what I told you about an application's memory limit. Every application can use up to 4GB of memory. Now, look at the number of bits set aside for pages under Windows, which is 10. The page table directory entries also have 10 bits set aside. If you take 210 page table directory entries, multiplied by 210 page table entries, multiplied by 4KB pages, you get 4GB.

After Windows finds a specific page within a specific page table, it takes the address it finds there and adds it to the offset in bits 11 through 0 of the address. These 12 bits allow an application to select any byte within the 4KB page.

Sleight-of-Hand Memory Management

Using 4KB pages provides a number of benefits when it comes to memory management. Remember in the preceding section when I talked about the page table directory and the page table? Each entry in these tables contains 32 bits of data, yet the actual pointers consume a lot less than that. What does the processor use the additional space for? I don't want to go into a blow-by-blow description of 80386 memory management. It might be useful to examine what some of these extra entries do, however. Fortunately, both tables use the same format, so I'll cover them at the same time.

Of course, the main purpose of using these tables in the first place is to point to something. That's what bits 31 through 12 do. In the page table directory, they point to a page table. In the page table, they contain the physical address that gets combined with the offset in the original address. Bit 6 contains the D (dirty) bit. Whenever an application changes the contents of a page of memory, Windows changes the dirty bit. This reminds the processor that it hasn't written the change to disk. If the processor wants to use this page of physical memory for some other purpose, it needs to write the existing page to the Windows swap file.

Bit 5 contains the A (accessed) bit. Whenever an application reads, writes, or executes a 4KB page of memory, Windows changes the status of this bit. Windows can use this bit to determine whether it should remove the page from memory to make room for something else.

Bit 2 contains the U/S (user/supervisor) bit. This is part of the 80386 protection scheme. If the bit is set to 0, it contains a supervisor page. Applications can never access supervisor pages because they belong to the operating system. On the other hand, setting the bit to 1 indicates that it's a user page. Applications can access any user page that belongs to them.

Bit 1 contains the R/W (read/write) bit. You wouldn't want an application to overwrite the code in a page. Setting this bit to 0 prevents an application from doing so. Data pages are set to 1; code pages are set to 0.

Bit 0 contains the P (present) bit. Windows needs to know whether a page is in physical memory. The application can't use a page of memory that's sitting on disk in the swap file. The page must reside in physical memory. If the application asks for access to a page of memory that is on disk, the processor raises an exception (basically, an alarm). This exception tells Windows that it needs to retrieve the page from its swap file on disk so that the application can access it.

As you can see, these table entries help Windows perform memory management sleight of hand. It can move 4KB pages from physical memory to disk as needed. Other bits protect operating system-specific memory from prying application eyes. Still other bits help protect your application from itself by preventing it from overwriting precious application code.

Virtual 86 Mode


Up to this point, you've seen how Windows manages memory for its own applications. What happens when you open a DOS box and run an application? The first thing to realize is that Windows takes a snapshot of your DOS environment before it completely boots. It creates a "phantom" DOS environment and holds onto it until needed. When you open a DOS box, Windows creates what is known as a virtual machine. This isn't a physical machine that you can touch, but it has all the capabilities of a standard 8086. After Windows creates this virtual machine, it copies the phantom DOS environment to it, and you have a DOS box. This DOS box has all the same device drivers and TSRs as the DOS environment you left when booting Windows.

What differentiates a virtual DOS machine from the rest of the Windows environment? The 80386 processor introduced a new mode called virtual 86 mode (V86), in which Windows can create multiple 8086s. Each of these virtual machines thinks that it's the only machine running. On the other hand, Windows applications run in protected mode. Windows has to switch between protected mode (to run Windows applications) and V86 mode (to run DOS applications). I won't go into the intricacies of how the processor switches between protected and V86 here; only a heavy-duty chip designer would enjoy that conversation. Each machine is totally separate, and V86 mode is a third mode that emulates real mode but doesn't actually run there.

Architectural Details


I've examined the problem of memory management from all angles now. You know what types of memory Windows NT uses or creates. I also examined the differences in the two memory models Windows NT has to use in order to support both 16-bit and 32-bit applications.

That's not quite the end of the story. It's not enough to simply say that you have certain types of memory available or that you know Windows NT has to use different methods to address it. Windows NT displays all these sources of information using a variety of window types. It looks like they're all in the same place working together.

Windows NT performs a certain level of "magic" to enable 16-bit and 32-bit applications to talk with each other. It also has to provide some method of reducing memory usage by optimizing the way it runs those applications. This section discusses both issues. I'll answer the question of how Windows NT allows you to run so many applications together under one roof.

Getting 16-Bit and 32-Bit Applications to Work Together


Windows NT consists of a combination of 16-bit and 32-bit applications. All those older applications and device drivers you use now have to work within the same environment as the new 32-bit drivers and applications that Windows NT provides. You already know how Windows takes care of separating the two by using different memory schemes. The 16-bit applications work within their own virtual machine area. It would be nice if things ended there, but they can't.

Sometimes, 16-bit and 32-bit applications have to talk to each other. This applies not only to programs the user employs to perform work, but also to device drivers and other types of Windows applications. Most Windows applications use a memory structure called the stack to transfer information from one application to another. Think of the stack as a database of variables. Each record in this database is a fixed length so that every application knows how to grab information from it. Here's where the problems start. The stack for 32-bit applications is 32 bits wide, which makes sense. It also makes sense that the stack for 16-bit applications is 16 bits wide. See the problem?

Of course, the problems are only beginning. What happens when you need to send a 32-bit value from a 16-bit application to a 32-bit application? The 32-bit application will expect to see the whole value in the EAX register. On the other hand, the 16-bit application expects to see the value in a combination of the DX and AX registers. This same problem translates to pointers as well. A 32-bit application, for example, will use the SS:ESP register pair to point to the stack.

But wait, there's more! Remember that 16-bit applications use a segmented address space. An address consists of a selector and an offset. A 16-bit application combines these two pieces to form a complete address. On the other hand, 32-bit applications use a flat address space. They wouldn't know what to do with a selector if you gave them one. All they want is the actual address within the total realm of available memory. How do you send the address of a string from a 16-bit to a 32-bit application?

By now, you're probably wondering how Windows keeps 16-bit and 32-bit applications working together. After all, it must deal with a number of inconsistencies and incompatibilities. The stack is only the tip of the incompatibility iceberg. It's easy to envision a method of converting 16-bit data to a 32-bit format. All you really need to do is pad the front end of the variable with zeros. How does a 32-bit application send data to a 16-bit application? If the 32-bit application just dumps a wide variable onto the stack, the 16-bit application will never know what do to with the information it receives. Clearly, the data needs to go through some type of conversion. Windows uses something called the thunk layer to enable 16-bit and 32-bit applications to communicate. Figure 8.7 shows the interaction of 16-bit and 32-bit applications through the thunk layer.

Figure 8.7. The thunk layer makes it possible for 16-bit and 32-bit applications to coexist peacefully under Windows.

As you can see, the three components of the API layer also provide translation services in addition to the other services they perform. Each API component translates the data and addresses within its area of expertise. The two GDI components translate all graphics data between 16-bit and 32-bit applications, for example.

Most thunking is pretty straightforward. Windows simply moves register data to the appropriate register, for example. The thunk layer builds a new stack to meet the needs of the application receiving it. Address translation takes a little more work. In addition, address translation is very expensive timewise. Every time Windows has to translate an address, it must perform several selector loads. The processor has to verify every selector load, so these translations can get cumbersome. Fortunately, you, as an application programmer, won't have to worry too much about the actual thunk process. What you do need to worry about is making certain that the process actually takes place when calling a piece of code that needs it.

Windows and DLLs


Under DOS, an application must contain every component it needs in order to execute. The programmer links in library support for graphics, low-level utilities, and a variety of other needs. Of course, this whole scenario is based on the fact that the application is the only thing running under DOS.

Windows is a different kind of environment because it always has more than one task running. Somewhere along the way, someone figured out that if you have multiple applications running, there might be some duplicate code out there as well. The display routines used by one application are probably the same as the display routines used by another application at some particular level, for example. The same person probably figured out that you can reduce the overall memory requirements of a system if you allow all the applications to share these redundant pieces of code instead of loading them from scratch for each application.

The dynamic link library (DLL) is the culmination of just such an idea. There are two forms of linking under Windows (or OS/2 or UNIX, for that matter). The first link combines all the object modules required to create a unique application. That link cycle happens right after the programmer finishes compiling the code. The second link cycle happens when the user loads the application. This is where the DLL comes in.

Every Windows application has unresolved references to functions. Microsoft calls them import library calls. These calls load a DLL containing the code required to satisfy that function call. If the DLL happens to be in memory when Windows calls it, Windows increments the DLL's usage level to indicate that more than one application is using the DLL. When an application stops using a DLL, Windows decrements its usage level. When the DLL's usage count is 0, Windows can unload it from memory. In effect, using DLLs can save quite a bit of memory when you're loading multiple applications.

What does this have to do with the API? The Windows API starts with three files, as just described. These three files call other files, however—DLLs, to be exact. Instead of creating three huge files, Microsoft chose to reduce the size of the Windows kernel by using DLLs.

This capability also makes Windows more flexible. Consider printer support. All you need to do to add printer support for a new printer is copy some files to disk. At least one of those files will be a DLL. Every printer DLL contains the same entry points (function names), so Windows doesn't need to learn anything new to support the printer. The only thing it has to do is install a new DLL. Your application performs the same task when you tell it to print. It looks at the DLLs currently installed for the system. The application doesn't have to care whether the printer is a dot matrix or a laser. All it needs to do is tell the printer to print; the DLL takes care of the rest.

Memory Tuning and Optimization Considerations


Any discussion of Windows and its evolution has to include the modes of operation that Windows supports. Previous versions of Windows supported three modes: real, standard, and 386 enhanced. Each mode supported a specific PC environment.

Real mode went out with the 80386 (and below) and Windows 3.x. Sure, some people are still using this kind of setup, but the actual number is decreasing daily. The reason is simple: Real mode is just too limited to perform any useful work, so I won't waste time talking about it here. Real mode is limited to a mere 1MB of memory—hardly enough to load Windows, much less applications.

The only reason for the existence of standard mode is the 80286. This mode enables Windows to run on a chip that provides access to only 16MB of RAM as a maximum and doesn't provide all the features that the 80386 does. The important feature the 80286 lacks is the capability to create virtual machines. Think of a virtual machine as a way of separating tasks so that they can't interfere with each other. Every application thinks it's running on its own machine, but each virtual machine is really part of the "real" machine you can see. Microsoft didn't even consider adding this mode to Windows NT (it doesn't appear in Windows 95 either), so I won't talk about it here. The following sections provide an overview of the remaining mode of operation: 386 enhanced mode.

Windows in 386 Enhanced Mode


You must have an 80386 or above processor to use 386 enhanced mode. This is the default mode that Windows 3.1 and above uses to get the most out of your machine. It offers all the features people normally associate with Windows now. Even though someone out there might be trying to run Windows in standard mode, most people switched to 80386 machines long ago. Several important features differentiate enhanced mode from standard mode:

It's not too difficult to imagine why 386 enhanced mode is the way to go if you have an 80386 machine to run Windows. In fact, I often wonder how people could expect to run Windows on an 80286 in the first place. Frankly, as I said in a column I wrote for PC Week many years ago, I wonder why anyone ever bought an 80286, but that's another story entirely. It's one of those "hindsight is 20/20" situations, I guess.

DOS Applications on Virtual Machines


Enhanced mode is the name of the game if you want to multitask DOS applications under Windows. As I stated earlier, this is the only mode you get with Windows 3.11 and above (including Windows NT). The underlying reason you can run more than one application is that the applications no longer load on the physical machine—instead, they load on a virtual machine. I have only one physical machine, so if I use it to run an application, there's nothing left to run something else. Virtual machines are different. Windows can continue to create new virtual machines as long as you have the memory to do so. Each virtual machine can run one DOS application. The capability to create multiple virtual machines means that you can always run more than one application.

What exactly is a virtual machine? I looked at many of the ramifications from an architectural point of view earlier in this chapter. Essentially, a virtual machine is a memory structure that acts like a physical machine. There used to be big gaps in this technology under Windows 3.x, but Microsoft has greatly improved the virtual machine under Windows NT. Of course, Windows NT is still far from perfect. Windows NT just can't cope when an application violates some rule of device or memory access, for example. It deals with this situation by terminating the application.

From a memory standpoint, Windows NT creates each virtual machine from extended memory. After it sets the memory aside, it loads a copy of DOS from the phantom copy Windows NT keeps around just for this purpose. It then loads and runs your DOS application. As far as the DOS application is concerned, it's running on its own 8088 machine. Of course, this application can still request expanded and extended memory. It can even use Windows DPMI services to switch to protected mode and run itself as a protected-mode application.

After you exit your DOS application, Windows destroys the virtual machine it used. It returns the memory used by the virtual machine to the system memory pool. Windows might decrease the size of your swap file (depending on your virtual memory settings and the current system load). Each DOS application you load gets a new virtual machine to operate in. Windows simply creates and destroys them as needed.

Getting Optimum Performance


Most of the following material is covered in other chapters. This is a good place to summarize the various tips and techniques I have presented, however (or will present in Chapter 13).



Note: You might ask yourself how much memory you need in order to obtain optimum performance. An operating system such as Windows NT doesn't have any theoretical limits as far as memory goes—at least, not that any of the current crop of desktop machines can achieve. The actual limiting factor is the machine's hardware (unlike Windows 95, which also experiences a few performance hits from using 16-bit components). From a practical point of view, though, you'll see performance top off at 64MB of RAM for most installations because everything should be loaded in memory at that point. Depending on your processor, you might actually see a performance drop-off starting at 128MB as Windows NT spends more time managing memory than using it. Your actual performance curve will vary, depending on a lot of factors, such as processor type and the number and size of applications you run.

Here are my top 10 tips and techniques for tuning your system to make the best use of memory:

  1. Always install Windows NT on a machine that can handle its advanced capabilities. Trying to run Windows NT on an underpowered machine is the best way to sap performance. A minimum Windows NT configuration uses a 66MHz 80486 with at least 16MB of RAM. The Microsoft stated minimum will only frustrate you and the person trying to get some work done.

  2. Use your fastest drive for the swap file, but don't starve Windows in the process. A fast drive will improve performance in one respect. A small swap file could kill that performance gain by reducing system stability and introducing some memory thrashing. Always choose the fastest drive that contains enough memory to hold the entire swap file.

  3. Manage your system, but don't micro-manage it. I can already see that this will be a major problem area for some users. Tune the individual files for the performance you need. Tell Windows what you need to do, but don't worry too much about how it gets the job done. I wouldn't have said this under Windows 3.x, but leaving Windows NT alone to do its work is about the best performance enhancement you can provide. (Of course, a little monitoring from time to time as your computing habits change wouldn't hurt either.)

  4. Never run more DOS sessions than you need. Windows NT does a much better job of managing memory when you have few DOS sessions going. In fact, you might even consider using all 32-bit applications—or at least as many as possible—to get the maximum performance benefits from Windows NT.

  5. Use the automatic memory settings whenever possible. Sometimes, you have to step in and adjust them manually if you have an application that starts by grabbing everything available. In most cases, though, you'll get ahead if you let Windows manage the memory for you. Letting Windows manage your memory provides a much greater degree of flexibility in the long run. That flexibility usually translates into increased efficiency and performance.

  6. Avoid running games and other surly programs under Windows NT. Consider using Windows 95 if you plan to run a lot of programs that break the rules Windows NT tries to enforce. If you do find an application that simply won't run using the default Windows memory setup, try creating an optimized environment for it using Windows 95's MS-DOS mode.

  7. Enhance your memory usage by getting rid of the frills. Wallpaper, excess icons, screen savers, and other doodads consume memory without giving you much in return. Entertainment is nice, but not at the cost of efficiency. The question you should always ask yourself is whether something relieves fatigue or merely consumes resources.

  8. Increase your level of physical RAM as needed. Windows NT can literally make as much RAM as you need from your hard drive, but there's a limit to how much performance you can get by doing this. I follow a simple rule: When the size of my swap file equals the amount of RAM in my machine on a consistent basis, it's time to buy more RAM.

  9. Get a faster hard drive. Swap files are a fact of life under Windows NT, and that means you're at least partially dependent on its speed for overall system performance—even when it comes to memory. I find that a drive with a higher level of throughput is a better choice than one with faster access time when it comes to memory management. Windows tends to read from the swap file in small, contiguous blocks. A drive with a higher throughput can deliver that data faster.

  10. Kill those old applications. If you're still using a lot of DOS applications, it's time to upgrade. Get rid of those old moth-eaten remnants. The only thing old DOS applications will do for you is slow down the system and cause reliability problems. Of course, 16-bit Windows applications aren't much better for the most part. Upgrading to the newer 32-bit applications helps you use memory efficiently and usually provides a speed benefit as well.


On Your Own


Open a DOS box and use the MEM command to see what kinds of memory you have available. Also note the amount of each type of memory you have available. If you don't see that both expanded and extended memory are available, try to discover the reason that one or the other is absent.

Explore the list of memory-tuning techniques in the preceding section. Can you use any of these tips to improve your machine's performance? Try different ways of implementing these changes to see what works best with your configuration. Windows NT is a new operating system, so you need to explore its weaknesses and strengths to see what you can do to improve your machine's capabilities. I think you'll find that many of the old techniques you used no longer work properly.

Previous Page Page Top TOC Next Page